kaiax/vrank: report candidate failures against the proposer's own pri… - #992

The non-epoch VRank cfReport carried a target block (the proposer's own most
recent prior proposal) alongside the failed candidate list. Scoring attributes
every failure to the reporting block's own proposer, so the target block changed
neither scoring nor the property that keeps a withheld or fabricated failure in
the reporting proposer's own byzantine-filterable column.

Remove it: the report becomes the failed address list, VerifyHeader drops the
prior/same-epoch/proposer-match checks and their errors, and the cross-epoch
guard in the CP-matrix aggregation (dead once the target is gone) is removed too.

Confidence: high
Scope-risk: narrow

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

The block's proposer is the only node that reports on a view — it evaluates the
candidate replies to its own proposal and records the result in its next
proposal. So a candidate now replies to that proposer alone instead of
broadcasting VRankCandidate to the whole committee, and only the proposer
records the preprepared time and collects the replies.

HandleVRankCandidate now accepts a reply only for a view this node proposed
(collector.HasPreprepared), which drops forged or misdirected messages before
signature recovery and bounds collector memory to the node's own pending
proposals. This removes the committee-wide collection path: the isCommitteeMember
gate, the prepreparedView field, and the prepreparedView-based staleness/window
guard (ErrPrepreparedViewNotSet, ErrTooFar) are no longer needed.

Confidence: high
Scope-risk: moderate

A non-epoch cfReport is about an earlier block of the same epoch, but VerifyHeader
resolves candidate membership at the reporting block's N-1. That holds because
CandTesting changes only at epoch transitions, and nothing pinned it: the other
subtests wire GetCandTesting to answer at any height, so the lookup height was
free to drift.

Confidence: high
Scope-risk: narrow

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The collector pruned views on a fixed 10-block window, which fit the old
committee-wide collection but not a proposer reporting on its own prior proposal
tens of blocks back. That gap was bridged by ownProposals: a second map of the
sequences this node proposed, passed in as a protected set the window had to
skip. The window was the wrong rule, and the protected set existed only to
survive it.

Prune by report progress instead. PruneReported(upto) drops every view below a
sequence, called with the block just reported (its own rounds stay, so a round
change or a failed commit re-reports it) and with the epoch start on each
proposal, which is the only drain for a node that never has a block to report.
selectReportTarget reads the pending sequences straight from the collector via
PendingEvaluations, so ownProposals, its mutex, and its three helpers are gone.

Confidence: high
Scope-risk: narrow

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>